Работаю с case-средством ERWin 7.1.2 (программа моделирования данных), не поддерживающим напрямую СУБД MySQL. Работаю с MySQL через ODBC-драйвера. ERWin имеет два уровня представления модели данных - логический, наиболее понятный разработчику, и физический, ориентированный и отражающий конкретную СУБД (в данном случае - MySQL 5, работа с которой происходит через ODBC 5).
При этом возникают вопросы/проблемы как с длиной физических имён таблиц, полей, индексов и др. объектов физической модели БД, так и с типами данных физической модели.
Перед рассмотрением проблем, имеющих место на физическом уровне, отмечу, что перед открытием модели данных я, а вернее, ERWin, через ODBC соединяется c сервером MySQL, что позволяет в дальнейшем работать на физическом уровне со специфическими особенностями MySQL (конкретными типами MySQL, длинами имён, ограничениями и т.д.).
Работаю с ERWin 7.1.2 (ERWin 7.1 SP2), MySQL 5.0.37 и ODBC-драйверами для MySQL (MyODBC) версии 5.00.11.
Проблемы/вопросы следующие:
1. При выборе в ERWin'е в качестве целевой платформы ODBC/Generic предлагается выбрать версию ODBC (ODBC/Generic Version): 2.0 или 3.0. Вопрос следующий: что это за версия - версия спецификации ODBC, согласно которой ERWin работает с ODBC-драйверами, или версия схемы, по которой ERWin генерирует родовые типы данных, т.н. generic datatypes, на логическом и физическом уровнях. (В случае соединения с сервером на физическом уровне вместо generic datatypes, отображаются конкретные типы СУБД).
Собственно, первый вариант отпадает потому, что спецификации ODBC имеют версии 2.50 и 3.5x (а не 2.0 и 3.0). Второй вариант кажется более правдоподобным. Хотя может быть, есть и другие варианты трактовки этой версии...
2. В ERWin'овском help'е в разделе "Generic Open Database Connectivity (ODBC)" говорится о т.н. generic datatypes, родовых типах (полный текст этого раздела приведён в конце данного трактата))). Из предложения "By using generic ODBC to connect to your database, you can replace any generic datatypes with the datatypes supported by your database" вытекает вывод, что термином "generic datatypes" называют типы данных логического уровня (собственно, типы данных доменов на логическом уровне), которые в ERWin'е приводятся в uppercase'е. Если ERWin соединился через ODBC с СУБД, то на физическом уровне эти generic datatypes заменяются конкретными типами СУБД, и уже не называются "generic datatypes".
По данному пункту возникают следующие три вопроса:
2.1. Каким образом ERWin формирует generic datatypes на логическом уровне (типы данных доменов) ? Набор этих типов жёстко задан разработчиками ?
2.2. Если мы не будем соединяться через ODBC с СУБД, то на физическом уровне также будут приведены физические типы данных, но уже не соответствующие реальным типам СУБД. Как называются эти физические типы данных, не соответствующие реальным типам СУБД ? Явно не generic datatypes, поскольку это не родовые типы, а конкретные типы СУБД...
2.2. Каким образом ERWin генерирует эти (см. предыдущий подпункт) физические типы данных, не привязанные (не соответствующие) реальным типам СУБД (т.е. когда мы не соединяемся через ODBC с СУБД и ERWin не знает конкретных типов СУБД) ?
3. На физическом уровне в свойствах модели в качестве максимальной длины имён таблиц, представлений, полей, индексов - в общем, всех объектов - допускается указывать максимум 30 символов, тогда как максимальная длина имён в MySQL - 64 символа. Такова ситуация при работе с ODBC (когда в качестве целевой СУБД выбираем ODBC/Generic). При работе с любой СУБД, напрямую поддерживаемой ERWin'ом, максимальная длина имён физической модели соответствует максимальной длине имён этой СУБД.
Выбирал ODBC/Generic Version как 2.0, так и 3.0. Ситуация не меняется. Устанавливал родные (с официального сайта MySQL) ODBC-драйвера для MySQL (т.н. MyODBC) версий как 3.51, так и 5.00 - ситуация прежняя, как со 2.0-й, так и с 3.0-й версиями ODBC/Generic для каждой из указанных версий MyODBC...
В чём может быть проблема ?
Собственно, мои варианты следующие. Во-первых, возможно, это глюк ERWin'а (ERWin 4.0 при работе с ODBC (при отсоединении от сервера) вообще выдаёт Runtime Error). Во-вторых, возможно, драйвера MyODBC не предоставляют функций для определения длины имён объектов СУБД (хотя это маловероятно). В-третьих, возможно, ERWin вообще не запрашивает у драйверов ODBC, с которыми работает, длин имён объектов и работает с ODBC всегда с 30-символьным ограничением (недоработка ERWin'а). Возможно, есть другие объяснения...
4. Как в ERWin при работе с MySQL через ODBC указать, что поле должно быть auto_increment ?
5. После того, как ERWin соединится через ODBC с сервером MySQL, на физическом уровне станут доступны конкретные типы данных MySQL. Так и происходит... но есть два больших "но". Во-первых, На физическом уровне доступны не все типы данных MySQL. И во-вторых, присутствуют некоторые типы, отсутствующие в MySQL 5, с которым происходит соединение.
На физическом уровне в ERWin 7 доступны следующие 18 типов:
* binary
* binary()
- bit
- char()
- date
- decimal(,)
- float
- integer
* long varbinary
* long varchar
- numeric(,)
- real
- smallint
- time
- timestamp
- tinyint
*varbinary()
- varchar()
Отмеченных звёздочкой типов в MySQL 5 нет.
Кроме того, в списке доступных отсутствуют следующие типы MySQL 5:
- tinyint()
- smallint()
- mediumint()
- int
- int()
- bigint
- bigint()
- bit()
- bool
- boolean
- decimal
- decimal(,)
- dec
- dec ()
- dec(,)
- numeric
- numeric()
- float(,)
- double
- double(,)
- real(,)
- double
- precision
- precision(,)
- tinyblob
- tinytext
- blob
- text
- mediumblob
- mediumtext
- longblob
- longtext
- enum
- set
- datetime
- timestamp()
- year
- year()
Список отсутствующих в ERWin типов настолько велик, что факт получения ERWin'ом через ODBC информации о типах MySQL ставится под сомнение...
Получает ли ERWin информацию о типах MYSQL или нет ?
Если да, то почему такие большие несоотвтетствия ?
_______________________________________________________________________________
Если ответов нет, просьба подсказать форумы, где можно выяснить приведённые вопросы.
Хотя, можно отписаться и на сам Computer Associates...
_______________________________________________________________________________
Текст раздела "Generic Open Database Connectivity (ODBC)" справочной системы ERWin 7.1.2.
AllFusion ERwin DM supports generic open database connectivity (ODBC) to extend its target server support. If your database runs on a target server that supports a generic ODBC driver, you can select ODBC/Generic as the target server in AllFusion ERwin DM. When you use generic ODBC to connect to a database, AllFusion ERwin DM queries the database to determine the physical properties it supports such as standard datatypes, user-defined datatypes, and physical storage objects.
When you choose ODBC/Generic as your target server, AllFusion ERwin DM immediately prompts you to connect to the database. If you:
1. Connect to the database, AllFusion ERwin DM queries the database to determine the datatypes and physical properties it supports and displays them in the AllFusion ERwin DM dialogs. By using generic ODBC to connect to your database, you can replace any generic datatypes with the datatypes supported by your database. Therefore, you may avoid related schema generation errors for invalid datatypes when you forward engineer your data model.
2. Do not connect to the database, the AllFusion ERwin DM dialogs include generic lists of datatypes and physical properties that you can assign to your data model objects. If you use the generic properties instead of those supported by your database, you may receive schema generation errors for invalid datatypes when you forward engineer your data model.
The generic ODBC driver that you use may have limitations that determine the type of information that AllFusion ERwin DM can query from the database. For example, if your ODBC driver cannot query a particular datatype, even when the datatype is supported by the database, the AllFusion ERwin DM dialogs may include only the physical properties the ODBC supports, not those physical properties the database supports. Similarly, when you reverse engineer a database using generic ODBC, AllFusion ERwin DM may be able to import only the objects from the database that the ODBC supports.
При этом возникают вопросы/проблемы как с длиной физических имён таблиц, полей, индексов и др. объектов физической модели БД, так и с типами данных физической модели.
Перед рассмотрением проблем, имеющих место на физическом уровне, отмечу, что перед открытием модели данных я, а вернее, ERWin, через ODBC соединяется c сервером MySQL, что позволяет в дальнейшем работать на физическом уровне со специфическими особенностями MySQL (конкретными типами MySQL, длинами имён, ограничениями и т.д.).
Работаю с ERWin 7.1.2 (ERWin 7.1 SP2), MySQL 5.0.37 и ODBC-драйверами для MySQL (MyODBC) версии 5.00.11.
Проблемы/вопросы следующие:
1. При выборе в ERWin'е в качестве целевой платформы ODBC/Generic предлагается выбрать версию ODBC (ODBC/Generic Version): 2.0 или 3.0. Вопрос следующий: что это за версия - версия спецификации ODBC, согласно которой ERWin работает с ODBC-драйверами, или версия схемы, по которой ERWin генерирует родовые типы данных, т.н. generic datatypes, на логическом и физическом уровнях. (В случае соединения с сервером на физическом уровне вместо generic datatypes, отображаются конкретные типы СУБД).
Собственно, первый вариант отпадает потому, что спецификации ODBC имеют версии 2.50 и 3.5x (а не 2.0 и 3.0). Второй вариант кажется более правдоподобным. Хотя может быть, есть и другие варианты трактовки этой версии...
2. В ERWin'овском help'е в разделе "Generic Open Database Connectivity (ODBC)" говорится о т.н. generic datatypes, родовых типах (полный текст этого раздела приведён в конце данного трактата))). Из предложения "By using generic ODBC to connect to your database, you can replace any generic datatypes with the datatypes supported by your database" вытекает вывод, что термином "generic datatypes" называют типы данных логического уровня (собственно, типы данных доменов на логическом уровне), которые в ERWin'е приводятся в uppercase'е. Если ERWin соединился через ODBC с СУБД, то на физическом уровне эти generic datatypes заменяются конкретными типами СУБД, и уже не называются "generic datatypes".
По данному пункту возникают следующие три вопроса:
2.1. Каким образом ERWin формирует generic datatypes на логическом уровне (типы данных доменов) ? Набор этих типов жёстко задан разработчиками ?
2.2. Если мы не будем соединяться через ODBC с СУБД, то на физическом уровне также будут приведены физические типы данных, но уже не соответствующие реальным типам СУБД. Как называются эти физические типы данных, не соответствующие реальным типам СУБД ? Явно не generic datatypes, поскольку это не родовые типы, а конкретные типы СУБД...
2.2. Каким образом ERWin генерирует эти (см. предыдущий подпункт) физические типы данных, не привязанные (не соответствующие) реальным типам СУБД (т.е. когда мы не соединяемся через ODBC с СУБД и ERWin не знает конкретных типов СУБД) ?
3. На физическом уровне в свойствах модели в качестве максимальной длины имён таблиц, представлений, полей, индексов - в общем, всех объектов - допускается указывать максимум 30 символов, тогда как максимальная длина имён в MySQL - 64 символа. Такова ситуация при работе с ODBC (когда в качестве целевой СУБД выбираем ODBC/Generic). При работе с любой СУБД, напрямую поддерживаемой ERWin'ом, максимальная длина имён физической модели соответствует максимальной длине имён этой СУБД.
Выбирал ODBC/Generic Version как 2.0, так и 3.0. Ситуация не меняется. Устанавливал родные (с официального сайта MySQL) ODBC-драйвера для MySQL (т.н. MyODBC) версий как 3.51, так и 5.00 - ситуация прежняя, как со 2.0-й, так и с 3.0-й версиями ODBC/Generic для каждой из указанных версий MyODBC...
В чём может быть проблема ?
Собственно, мои варианты следующие. Во-первых, возможно, это глюк ERWin'а (ERWin 4.0 при работе с ODBC (при отсоединении от сервера) вообще выдаёт Runtime Error). Во-вторых, возможно, драйвера MyODBC не предоставляют функций для определения длины имён объектов СУБД (хотя это маловероятно). В-третьих, возможно, ERWin вообще не запрашивает у драйверов ODBC, с которыми работает, длин имён объектов и работает с ODBC всегда с 30-символьным ограничением (недоработка ERWin'а). Возможно, есть другие объяснения...
4. Как в ERWin при работе с MySQL через ODBC указать, что поле должно быть auto_increment ?
5. После того, как ERWin соединится через ODBC с сервером MySQL, на физическом уровне станут доступны конкретные типы данных MySQL. Так и происходит... но есть два больших "но". Во-первых, На физическом уровне доступны не все типы данных MySQL. И во-вторых, присутствуют некоторые типы, отсутствующие в MySQL 5, с которым происходит соединение.
На физическом уровне в ERWin 7 доступны следующие 18 типов:
* binary
* binary()
- bit
- char()
- date
- decimal(,)
- float
- integer
* long varbinary
* long varchar
- numeric(,)
- real
- smallint
- time
- timestamp
- tinyint
*varbinary()
- varchar()
Отмеченных звёздочкой типов в MySQL 5 нет.
Кроме того, в списке доступных отсутствуют следующие типы MySQL 5:
- tinyint()
- smallint()
- mediumint()
- int
- int()
- bigint
- bigint()
- bit()
- bool
- boolean
- decimal
- decimal(,)
- dec
- dec ()
- dec(,)
- numeric
- numeric()
- float(,)
- double
- double(,)
- real(,)
- double
- precision
- precision(,)
- tinyblob
- tinytext
- blob
- text
- mediumblob
- mediumtext
- longblob
- longtext
- enum
- set
- datetime
- timestamp()
- year
- year()
Список отсутствующих в ERWin типов настолько велик, что факт получения ERWin'ом через ODBC информации о типах MySQL ставится под сомнение...
Получает ли ERWin информацию о типах MYSQL или нет ?
Если да, то почему такие большие несоотвтетствия ?
_______________________________________________________________________________
Если ответов нет, просьба подсказать форумы, где можно выяснить приведённые вопросы.
Хотя, можно отписаться и на сам Computer Associates...
_______________________________________________________________________________
Текст раздела "Generic Open Database Connectivity (ODBC)" справочной системы ERWin 7.1.2.
AllFusion ERwin DM supports generic open database connectivity (ODBC) to extend its target server support. If your database runs on a target server that supports a generic ODBC driver, you can select ODBC/Generic as the target server in AllFusion ERwin DM. When you use generic ODBC to connect to a database, AllFusion ERwin DM queries the database to determine the physical properties it supports such as standard datatypes, user-defined datatypes, and physical storage objects.
When you choose ODBC/Generic as your target server, AllFusion ERwin DM immediately prompts you to connect to the database. If you:
1. Connect to the database, AllFusion ERwin DM queries the database to determine the datatypes and physical properties it supports and displays them in the AllFusion ERwin DM dialogs. By using generic ODBC to connect to your database, you can replace any generic datatypes with the datatypes supported by your database. Therefore, you may avoid related schema generation errors for invalid datatypes when you forward engineer your data model.
2. Do not connect to the database, the AllFusion ERwin DM dialogs include generic lists of datatypes and physical properties that you can assign to your data model objects. If you use the generic properties instead of those supported by your database, you may receive schema generation errors for invalid datatypes when you forward engineer your data model.
The generic ODBC driver that you use may have limitations that determine the type of information that AllFusion ERwin DM can query from the database. For example, if your ODBC driver cannot query a particular datatype, even when the datatype is supported by the database, the AllFusion ERwin DM dialogs may include only the physical properties the ODBC supports, not those physical properties the database supports. Similarly, when you reverse engineer a database using generic ODBC, AllFusion ERwin DM may be able to import only the objects from the database that the ODBC supports.