3.4. Пример проектирования даталогической модели

Спроектировать даталогичеекую структуру БД означает установить все информацион-ные единицы и связи между ними, задать их имена. Если для информационных единиц возможно использование разных типов, то необходимо определить их тип.

Процесс проектирования БД предусматривает предварительную классификацию объектов предметной области, систематизированное представление информации об объектах и связях между ними. На начальных этапах проектирования должен быть выявлен состав БД.

При проектировании логической структуры БД преобразовывается исходная инфологи- ческая модель в модель данных, поддерживаемую конкретной СУБД, а также проверяется адекватность полученной даталогической модели отображаемой предметной области. Связи между сущностями предметной области, отраженные в инфологической модели, могут отображаться в даталогической модели либо посредством совместного расположения соответствующих им информационных элементов, либо объявления связи между ними.

Рассмотрим технологическую сеть проектирования для стадии логического проектирования БД (рис. 3.10). Заметим, что при переходе от инфологической модели к дата- логической следует иметь в виду, что инфологическая модель включает всю информацию о предметной области, необходимую и достаточную для проектирования БД. Это не означает, что все сущности, зафиксированные в инфологической модели, должны в явном виде отражаться в даталогической модели. Прежде чем строить даталогичеекую модель, целесообразно решить, какая информация будет храниться в БД (например, в инфологической модели должны быть отражены вычисляемые показатели, но вовсе не обязательно, чтобы они хранились в БД).

Рис. 3.10. Технология проектирования даталогической модели БД: Дт —документация по СУБД; Дг... Д, — документация по средствам проектирования; L/, — набор допустимых даталогических конструкций; U2 — операторы; U3 — ограничения, налагаемые СУБД; (Л — возможности физической организации данных; ДМ — даталогическая модель; ИМ — инфологическая модель; Пі — перечень хранения показателей; Si — средство (методика проектирования)

- Существуют разные подходы к определению состава показателей, которые должны храниться в БД.

Такой подход имеет следующие достоинства:

простота и однозначность в принятии решения «что хранить»;

отсутствие неявного дублирования информации со всеми вытекающими из этого последствиями (меньше объем памяти, чем при хранении как исходных, так и производных показателей, проще проблемы контроля целостности данных);

потенциальная возможность получить любой расчетный показатель, а не только те, которые хранятся в БД.

К основным характеристикам поля относятся его тип и длина. Каждое отношение по определению имеет ключ, т.е. атрибут (простой ключ) или совокупность атрибутов (составной ключ). Отношение, соответствующее сущности, содержит атрибуты (столбцы), которые служат атрибутами сущности и описывают сущность (объект).

Атрибут или множество атрибутов, которое однозначно характеризует объект, называется ключом. Различают два вида ключей, которые обладают следующими свойствами:

первичный ключ (ПК) — родительская сущность входит в состав дочерней, т.е. это набор атрибутов, уникально идентифицирующих экземпляр сущности;

внешний ключ (ВК) — необходим для связи с другой таблицей, ссылается на другую таблицу, мигрирует из главной таблицы в дочернюю.

Логическое проектирование реляционных БД заключается в распределении информации по файлам. Конечным результатом даталогического проектирования является описание логической структуры БД на языке описания данных.

Для среды программирования Borland Delphi конечный шаг — это создание сценариев Data Definition Language (DDL), применяемых для создания таблиц. Каждой сущности поставлены в соответствия определенные отношения с выделением в них первичных и внешних (вторичных) ключей.

Основываясь на описание предметной области, в рассматриваемом случае были выделены следующие отношения:

«Пользователи» — картотека пользователей услуг связи;

«Отбор дебиторов» — содержит легенду дат и критериев отбора дебиторов;

«Расчеты» — содержит легенду по месячным периодам расчетов с пользователями;

«Сальдо» — включает сведения о сальдо плательщиков на момент закрытия месяца;

«Подразделения» — картотека подразделений оператора связи;

«Услуга» — имеет сведения о состоянии услуги;

«Долг» — содержит сведения о задолженности пользователя в каждый расчетный период в течение одного этапа работы с ним как с дебитором;

«Операторы» — операторы, работающие с автоматизированной системой бухгалтерского учета;

<Дебиторы» — идентифицирует попадание пользователя в дебиторы и вероятное начало работы с ним;

«Список абонентов» — список абонентов, для которых следует выполнить однотипную операцию;

«Описание абонентов» — описание списка абонентов, для которых следует осуществить однотипную операцию.

В результате даталогического проектирования БЗ и БД каждому отношению был поставлен в соответствие набор атрибутов.

К атрибутам отношения «Пользователи» (Users) относятся:

идентификатор пользователя (UsersID) ПК;

идентификатор отделения банка (Bank Dept ID) ВК;

идентификатор отделения, которому платит данный пользователь за услуги связи (DEPT ID) ВК;

идентификатор типа пользователя (User Type_ID) ВК;

идентификатор улицы (Street_ID) ВК;

идентификатор пункта приема оплаты (POS_ID) ВК;

номер лицевого счета (Account);

наименование пользователя (Name);

ИНН (INN);

дата открытия лицевого счета (DateBegin);

дата закрытия лицевого счета (Date_End);

почтовый индекс (Post Index);

дом (Home);

корпус (Corpus);

квартира (Flat);

предприятие (физическое или юридическое лицо) (is Corp);

дата заключения договора (Contract Date);

номер договора на предоставление услуг связи (Contract Nmb);

расчетный счет банка (Bank Account);

код предприятия по классификатору предприятий (ОКРО);

телефон юридического местоположения (J_Fhone);

телефон физического местоположения (F Fhone).

Атрибутами отношения «Отбор дебиторов» (ToDebet) являются:

идентификатор выполненной процедуры отбора дебиторов (Dbt Lgnd ID) ПК;

идентификатор отделения, которому платит данный пользователь за услуги связи (DEPT ID) ВК;

идентификатор списка пользователей (User_List_ID) ВК;

идентификатор периода расчета, на основании которого отыскиваются дебиторы (Calc ID) ВК;

идентификатор оператора, выполнявшего поиск (ОрегГО) ВК;

физическое или юридическое лицо (is Corp);

величина долга для населения (Limit); User Saldo Calculator ToDebet User ID: N (ПК) BankDept ID: N (ВК) DEPT ID: N (ВК) UserType ID: N (BK) Street ID: N (BK) POSJD: N (BK) Account: S Name: A INN: S

Date Begin: D Date_End: D Postlndex:S Home: S Corpus: S Flat: S isCorp:S ContractDate: D ContractNmb: S BankAccount: S OKPO: S J-Phone: S F.Phone: S <— User ID: N (BK) Calc ID: N (BK) Saldo ID: N (BK) Tax: N nDolg: N Calc ID: N (ПК) CalcDate: D PeriodName: S Calc Month: D Calc.Year: D SuccessKey: S DbtLgnd ID: N (ПК) DEPT ID: N (BK) User List ID: N (BK) Calc ID: N (BK) OperJD: N (BK) isCorp:S Limit: N isPercent: S nDolg: N xDate: D PrintDate: D SuccessKey:S SendOtkl: N GetOtkl: N OtclList: N SendRemove: N GetRemove: N RemoveList: N ObzvonD: N DpreRemove: N DspRemove: N —» »

» «

( i--» 1» Podraz

DEPT ID: N (ПК) Street ID: N (BK) POS ID: N (BK) Code: S Name: A BankAccount: S Home: S OKPO: S J_Phone: S F_Phone: S Ref Phone: S INN: S ATS_Nmb: N Г* Debetors

Dbt ID: N (ПК) User ID: N (BK) DEPTJD: N (BK) SvcType: S OtklCounter: N OtklWDate: D GetOtklWDate: D OtklListDate: D RemCounter: N RemWDate: D GetRemWD: D RemListDate: D PayDate: D Debet: N nDolg: N isCorp: S UserJypeJD: N —» —» Dolg User List Dbt ID: N (BK) DEBT ID: N (BK) Calc ID: N (BK) User ID: N Debet: N nDolg: N —

<

« User ID: N (BK) UserJistJD: N (BK) «— « Г» < Operators AbUser_List Sv_Service User List ID: N (BK) OperJD: N (BK) Name: A isCorp: S Info:A List_Date: D OperJD: N (ПК) Name: A Login_Name: A Oper^Nmb: N Service ID: N (BK) Dbt ID: N (BK) Status: S Date^Begin: D с «

Рис. 3.11.

количество месяцев долга для населения (n Dolg);

дата проведения процедуры поиска (х Date);

дата печати предупреждений (Print Date);

ключ завершения поиска дебиторов (Success Key);

посылать на отключение дебитора (send otkl);

отключить телефон (get otkl);

список дебиторов на отключение (Otkl list);

посылать на снятие (удаление) телефона (send remove);

снять (удалить) телефон (get remove);

список телефонов на снятие (remove list);

обзвон дебиторов (Obzvon D);

предварительное снятие телефона дебитора (Dpre Remove);

список снятых телефонов дебитора (Dsp Remove).

К атрибутам отношения «Расчеты» (Calculation) относятся:

идентификатор расчетного периода (CalcID) ПК;

дата закрытия месяца (Calc Date);

наименование периода расчета (Period Name);

месяц закрытия (Calc Month);

год (Calc Year);

ключ завершения расчета (Success Key).

Атрибутами отношения «Сальдо» (Saldo) являются:

идентификатор пользователя (Users ID) ВК;

идентификатор периода расчета (Calc ID) ВК;

сальдо (Saldo);

в том числе налог (Tax);

количество месяцев долга (n Dolg).

Атрибуты отношения «Подразделения» (Podraz):

идентификатор отделения, которому платит пользователь за услуги связи (DEPT ID) ПК;

идентификатор улицы (Street ID) ВК;

идентификатор пункта приема оплаты (POS ID) ВК;

код подразделения оператора связи (Code);

наименование подразделения оператора связи (Name);

расчетный счет банка (Bank Account);

дом (Home);

код предприятия по классификатору предприятий (ОКРО);

телефон юридического местоположения (J Phone);

телефон физического местоположения (F_Phone);

телефон для справок (используется для АТС) (Ref Phone);

ИНН (INN);

номер АТС (ATS Number).

Атрибуты отношения «Услуга» (Sv_ Service):

идентификатор услуги (Service_ID) ПК;

идентификатор дебитора для периода работы с ним (DbtID) ВК;

состояние услуги (Status):

включение или установка;

пользование услугой;

отключение услуги;

дата начала действия установки (Date Begin);

Атрибуты отношения «Долг» (Dolg):

идентификатор дебитора для периода работы с ним (Dbt_ID) ВК;

идентификатор отделения, которому платит пользователь за услуги связи (DEPTID) ВК;

идентификатор расчетного периода, выставление счета (Calc_ID) ВК;

идентификатор пользователя (Users ID);

величина задолженности пользователя (Debet);

количество месяцев задолженности (n Dolg).

Атрибуты отношения «Операторы» (Operators):

идентификатор оператора, выполнявший поиск (Орег Ю) ПК;

наименование подразделения оператора связи (Name);

ввод имени оператора (Login Name);

номер оператора (Oper Nmb).

Атрибуты отношения «Дебиторы» (Debetors):

идентификатор дебитора для периода работы с ним (Dbt ID) ПК;

идентификатор пользователя (дебитора) (Users ID) ВК;

идентификатор подразделения оператора связи, чьи услуги будут отключены (DEPT ID) ВК;

тип услуг, об отключении которых предупреждается дебитор (Svc Туре);

количество высланных предупреждений об отключении (Otkl Counter);

дата посылки предупреждения об отключении (Otkl W Date);

дата подтверждения получения предупреждения об отключении (Get Otkl W Date);

дата включения в список на отключение (Otkl List Date);

количество высланных предупреждений о снятии (Rem Counter);

дата посылки предупреждения о снятии услуг, расторжение договора (Rem W Date);

дата подтверждения получения предупреждения о снятии (Get Rem WD);

дата включения в список на снятие (Rem List Date);

дата погашения задолженности (Pay Date);

текущая задолженность (Debet);

текущий долг (n Dolg);

предприятие (физическое или юридическое лицо) (is Corp);

идентификатор типа пользователя (User Type_ID).

Атрибуты отношения «Список абонентов» (User List):

идентификатор абонента (Users ID) ВК;

идентификатор списка абонентов (User List ID) ВК; Атрибуты отношения «Описание абонентов» (Ab User List):

идентификатор списка абонентов (User List ID) ПК;

идентификатор оператора, выполнявшего поиск (Oper lD) ВК;

наименование списка абонентов (Name);

предприятие (физическое или юридическое лицо (is Corp);

описание списка абонентов (Info);

дата составления списка абонентов (List Date).

Рассмотренные выше связи между таблицами можно организовать как на этапе конструирования БД, так и программно.

Все связи реализуются преимущественно программным путем. Для реализации связей при проектировании необходимо обеспечить их типовую совместимость, соответствующие поля в разных таблицах должны иметь один и тот же тип и одинаковую длину, что и было сделано в процессе физического проектирования.