46634 (607889), страница 2
Текст из файла (страница 2)
Примечание: Диаграммы SADT 0,1,2- уровней см. в приложении 1.
2.3 Определение информационных объектов и связей между ними
В семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLeon) в 1981 году, функциональную модель данных Шипмана (Shipman), а также созданную
В 1981году, модель «сущность-связь», предложенную Ченом (Chen) в 1976 году, и ряд других моделей. В настоящий момент именно модель Чена «сущность-связь», или «Entity Relationship», стала фактическим стандартом в моделировании баз данных. Общепринятым стало сокращенное название ER-модель.
Как любая модель, модель «сущность-связь» имеет несколько базовых понятий, которые образуют исходные кирпичики, из которых строятся уже более сложные объекты по заранее определенным правилам.
В основе ER-модели лежат следующие базовые понятия: Сущность, с помощью которой моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов-характеристик, определяющих свойства данного представителя класса. Между сущностями могут быть установлены связи. Связи делятся на три типа по множественности:
Один-к-одному (1:1)-означает, что экземпляр одной сущности связан с только с одним экземпляром другой сущности.
Один-ко-многим (1:M)-означает что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи.
Многие-ко-многим (M:M)-означает, что один экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и наоборот, один экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности.
Для более полного понимания зависимости информационной системы, рассмотрим диаграммы «сущность - связь». Имеется четыре сущности: «Торговый чек», «Счет-фактура», «Покупатель» и «Автомобили». Таблица «Покупатель» связана с таблицей «Торговый-чек» связью Один-ко-многим. Аналогичной связью связаны «Торговый-чек» и «Счет-фактура» с таблицей «Автомобили». Рассмотрим связи присутствующие в данной курсовой работе.
Таблица «Торговый чек» связана с таблицей «Покупатель» следующей связью:
Связь «Отпуск товара по коду покупателя» подразумевает, что при вводе нового покупателя в таблицу «Торговый-чек» автоматически добавляется код покупателя, т.е. по полю “код покупателя” можно будет сделать необходимый запрос.
Т аблица «Счет-фактура» и «Торговый-чек» связана с таблицей «Автомобили» следующими связями:
Связь «Приобретение товара по номеру счета-фактуры» подразумевает, что при вводе нового счета-фактуры в таблицу «Автомобили» автоматически добавляется поле “номер счета-фактуры”.
Связь «Отпуск товара по номеру счета-фактуры» подразумевает, что при вводе нового поля “номер торгового чека” в таблицу «Автомобили» автоматически добавляется номер этого торгового чека.
Связь «Отпуск товара по коду покупателя» подразумевает, что при вводе нового покупателя в таблицу «Торговый-чек» в таблицу «Автомобили» автоматически добавляется код-покупателя.
Примечание: * - ключевые поля во всех таблицах.
2.4 Структурный анализ с помощью диаграмм “сущность - связь”
В данной курсовой работе присутствуют следующие таблицы:
Таблица 1: Автомобили (Avtom.db);
Имя поля | Тип данных | Размер поля |
N_Scheta_Fak | Числовой | |
Kod_Modeli | Счетчик | |
Name_Modeli | Текстовый | 15 |
Color | Текстовый | 10 |
Predlag_Zena | Денежный | |
Kol_vo_Door | Числовой | |
Engine_Power | Числовой | |
Type_Salon | Текстовый | 10 |
Таблица 2: Покупатели (Pok.db);
Имя поля | Тип данных | Размер поля |
Kod_Pokup | Текстовый | 10 |
Seria_Pass | Текстовый | 10 |
N_Pass | Текстовый | 10 |
L_Name | Текстовый | 20 |
F_Name | Текстовый | 20 |
S_Name | Текстовый | 20 |
Adres | Текстовый | 20 |
Phone | Текстовый | 20 |
Таблица 3: Счет-фактура (SchFa.db);
Имя поля | Тип данных | Размер поля |
N_Scheta_Fak | Числовой | |
Kol_vo_zakup_modelei | Текстовый | 10 |
Nazv_Zakup_Modeli | Текстовый | 15 |
Zavodsk_Zena | Денежный | |
Date_Zakup | Дата |
Таблица 4: Торговый чек (Torg_Chek);
Имя поля | Тип данных | Размер поля |
N_Torg_Cheka | Счетчик | |
Kod_Pokup | Текстовый | 10 |
Kod_Modeli | Текстовый | 10 |
Kol_Prod_Avto | Числовой | |
Zena_Prod | Денежный | |
Date_Prod | Дата |
Определение ключевых полей в таблицах:
Название таблицы | Название ключевого поля |
Автомобили | Номер Счета-фактуры |
Покупатели | Код покупателя |
Счет-фактура | Номер Счета-фактуры |
Торговый-чек | Номер Торгового чека |
Рис 2. Диаграмма “сущность-связь” (IDEF 1x).
Пояснения:
Первичные ключи следующие:
Таблица: Автомобили – Kod_Modeli.
Таблица: Покупатель – Kod_Pokup.
Таблица: Счет-фактура – N_Scheta_Fak.
Таблица: Торговый чек – N_Torg_Cheka.
Внешние ключи следующие:
Таблица: Автомобили – N_Scheta_Fak.
Таблица: Автомобили – N_Torg_Cheka.
Таблица: Автомобили – Kod_Pokup.
Таблица: Торговый чек – Kod_Pokup.
Таблица: Автомобили – N_Scheta_Fak.
Р ис 3. Диаграмма “сущность-связь” на русском языке.
2.5 Определение пакета форм ввода/вывода
Входными данными являются данные с формы Счет-фактура, т.к. закупка товара производится по “Счету-фактуре”.
Ввод данных осуществляется с помощью формы “новый счет-фактура”.Выходными данными являются данные с формы “Торговый чек”, т.к. отпуск товара осуществляется по этой форме.
Ввод данных на отпуск товара осуществляется с помощью формы “новый торговый чек”.
Замечание: На форме новый “новый торговый чек” присутствует элемент DBNavigator, он необходим для того чтобы, выбрать необходимую модель автомобиля. Причем цена на автомобиль выставляется автоматически в зависимости от выбранного кода модели.
3. Реализация информационной системы средствами объектно-ориентированного языка Delphi
Delphi – это среда разработки приложений с использованием графического интерфейса Windows. Программирование является:
а) Объектно-ориентированным (программирование осуществляется над объектами и с помощью объектов)
б) Событийно-ориентированным (раз есть объект, то должно быть и событие на которое реагирует объект). Программирование в Delphi осуществляется с помощью объектов, каждый объект имеет свойства.
Средства Delphi для разработки приложений, использующих базы данных:
BDE (Borland Database Engine).
Взаимодействие приложения, созданного в среде разработке Delphi, и базы данных обеспечивает процессор баз данных Borland Database Engine. Он представляет собой набор динамических библиотек, функции которых позволяют не только обращаться к данным, но и эффективно управлять ими на стороне приложения. Компоненты доступа к данным Delphi для работы с базами данных используют возможности BDE, обращаясь к его функциям и процедурам. Механизм доступа к BDE инкапсулирован в базовом классе TBDEDataSet. BDE взаимодействует с базами данных посредствам драйверов. Для наиболее распространенных СУБД разработан набор стандартных драйверов. Однако при всех преимуществах BDE не претендует на всеобъемлющую универсальность и имеет некоторые недостатки. К ним, например, относится снижение скорости работы приложения, недостатки реализации некоторых драйверов.
SQL Links.
Приложения Delphi обращаются к данным при помощи BDE, при этом способы доступа к данным различаются в зависимости от типа базы данных. К локальным БД Paradox, dBASE, MS Access, FoxPro BDE обращается посредствам стандартных драйверов. Данные от серверов SQL поступают благодаря использованию специальной системы драйверов SQL Links. Важнейшую роль при обработке и отправлении запроса играет составная часть процессора БД-система обработки запросов. Локальные СУБД не используют язык SQL в качестве основного при работе с данными. Тем не менее, BDE при помощи соответствующего стандартного драйвера транслирует поступающие от приложений запросы в понятный для локальной СУБД вид и принимает ответы. Так как запрос к любой локальной БД выполняется одним механизмом, то существует и единый синтаксис SQL для работы с такими данными. Этот вариант носит название локальный SQL и является подмножеством стандарта SQL 92. Все серверы БД, работающие через SQL Links, являются серьезными промышленными системами и работают на собственных расширениях языка.
BDE Administrator.
Для успешного доступа к данным приложение и BDE должны обладать информацией о местоположении файлов требуемой базы данных. Самый простой способ заключается в явном задании полного пути к каталогу, в котором хранятся файлы БД. Но в случае изменения пути, что случается не так уж редко (например, при переносе готового приложения на компьютер заказчика), разработчик должен перекомпилировать проект с учетом будущего местонахождения БД или предусмотреть специальные элементы управления, в которых можно задать путь к БД. Для решения такого рода проблем разработчик может использовать псевдоним базы данных, который представляет собой именованную структуру, содержащую путь к файлам БД и некоторые дополнительные параметры. Помимо маршрута к файлам базы данных, псевдоним BDE обязательно содержит информацию о драйвере БД, который используется для доступа к данным. Наличие других параметров зависит от типа драйвера, а значит от типа СУБД. Для управления псевдонима баз данных, настройки стандартных и дополнительных драйверов в составе BDE имеется специальная утилита - ВDЕ Adminstrator (см. выше, исполняемый файл BDEADMIN.EXE). Стандартная конфигурация BDE сохраняется в файле IDAPI.CFG.
Database Desktop.
Это программа для создания, редактирования, удаления, изменения логической структуры таблиц баз данных.
3.1 Конфигурация системы с помощью утилиты
BDE ADMINISTRATOR
Данная курсовая работа не нуждается в создании псевдонима. Она лишь требует следующего: