Создание программного обеспечения для небольшого супермаркета
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
ое программирование только усилило значимость этого подхода.
В работе БД возможен одно- и многопользовательский (несколько пользователей подключаются к одному компьютеру через разные порты) режимы.
БД используются обычно не самостоятельно, а являются компонентой различных информационных систем: банков данных, информационно-поисковых и экспертных систем, систем автоматизированного проектирования, автоматизированных рабочих мест, автоматизированных систем управления.
Создать саму БД (не СУБД) средствами Delphi очень сложно, даже невозможно. Если выбрать двух- или трехзвенную архитектуру, не обойтись без сервера БД, который создать собственными силами очень трудно (да и ни к чему, если на рынке предлагаются десятки таких программ, а в Интернете при желании можно найти и бесплатный, но вполне приличный сервер MySQL).
Если речь идет о файл-серверной БД, то и здесь понадобятся специальные средства. В Delphi для этих целей обычно используется утилита Database Desktop.
Могут также применяться промышленные СУБД Paradox*-, dBASE (корпорации Borland), FoxPro, Access (корпорации Microsoft) и др. В рамках данной дипломной работы используются средства Database Desktop и сервер InterBase, так как они входят в комплект поставки Delphi и являются собственными продуктами корпорации Borland.
Создание БД начинается с ее проектирования. На этом этапе анализируются информационные потоки iелью определить набор таблиц и их полей. Процесс проектирования в немалой степени зависит от опыта и интуиции разработчика, то есть является творческим, однако некоторые его моменты можно формализовать. Одной из таких формализации является требование, согласно которому реляционная база данных должна быть нормализована.
Нормализованной называется БД, в которой выполняется как минимум 3 условия. Выполнение условия называется приведением БД к соответствующей нормальной форме.
Первая нормальная форма (1НФ) требует, чтобы каждое поле таблицы было неделимым и не содержало повторяющихся групп. Пусть в таблице хранится информация о книгах. Эту информацию можно держать в единственном поле, но это противоречит 1НФ. В соответствии с ней в таблице должны быть поля Название, Автор, Издательство и др., совокупность которых дает исчерпывающую информацию о книге. Это облегчает реализацию таких запросов к БД, которые позволят узнать количество разных авторов, количество книг одного автора, количество книг, выпущенных определенным издательством, и т. п. Повторяющимися являются поля, содержащие сходную информацию. Если, например, таблица содержит информацию о покупателе и купленных им книгах, то, в соответствии с 1НФ, список книг должен выделяться в отдельную таблицу.
В этом случае таблица покупателей будет главной, а таблица купленных ими книг - детальной. Между такими таблицами должна устанавливаться реляционная связь один ко многим.
Вторая нормальная форма (2НФ) требует, чтобы все поля одной таблицы зависели от первичного ключа - только в этом случае первичный ключ, как и требуется, будет определять уникальную информацию. Допустим, что мы в таблице отпуска книг составили первичный ключ по полям Номер накладной и Покупатель. Нетрудно заметить, что такой ключ будет избыточным: поле Покупатель однозначно определяется номером накладной, поэтому, в соответствии с 2НФ, оно не может входить в первичный ключ.
Третья нормальная форма (ЗНФ) требует, чтобы значение любого поля, не входящего в первичный ключ, никак не зависело от значения других полей. Если в таблице накладных содержатся поля Книга и Отпускная цена, второе поле явно зависит от первого и по требованию ЗНФ должно быть вынесено в отдельную таблицу. Общее правило выполнения ЗНФ таково: в таблице должны быть только не зависящие друг от друга поля, однозначно определяющие некоторый факт, вся дополнительная информация о значении полей должна выноситься в отдельные таблицы. Например, в той же накладной на продажу книг должно быть поле Покупатель, но не должно быть характеризующих его полей Город, Адрес, Телефон и т. п. - эти данные должны быть в отдельной таблице Покупатели.
Как уже говорилось, проектирование БД - творческий процесс, а описанные выше требования носят лишь рекомендательный характер. На практике безусловное выполнение этих требований (в особенности ЗНФ) приводит к появлению множества небольших по объему таблиц и может существенно замедлять работу с СУБД. Для повышения скорости ее работы проектировщики часто идут на сознательное нарушение описанных требований.
Единицей хранящейся в БД информации является таблица. Каждая таблица представляет собой совокупность строк и столбцов, где строки соответствуют экземпляру объекта, конкретному событию или явлению, а столбцы - атрибутам (признакам, характеристикам, параметрам) этого объекта, события, явления.
В терминах БД столбцы таблицы называются полями, а ее строки - записями.
Базы данных, между отдельными таблицами которых существуют связи, называются реляционными (от relation - связь, отношение).
Связанные отношениями таблицы взаимодействуют по принципу главная (master) - детальная (detail).
В каждой таблице БД может существовать первичный ключ - поле или набор полей, однозначно идентифицирующий запись. Значение первичного ключа в таблице БД должно быть уникальным, то есть в таблице не должно существовать двух или более записей с одинаковым значением первичного ключа.
Первичные ключи облегчают установление связи между таблицами.
Поскольку первичный ключ должен бы