МИНИСТЕРСТВО ВЫСШЕГО И СРЕДНЕГО СПЕЦИАЛЬНОГО
ОБРАЗОВАНИЯ РЕСПУБЛИКИ УЗБЕКИСТАН
МИНИСТЕРСТВО ПО РАЗВИТИЮ ИНФОРМАЦИОННЫХ
ТЕХНОЛОГИЙ И КОММУНИКАЦИЙ РЕСПУБЛИКИ
УЗБЕКИСТАН
САМАРКАНДСКИЙ ФИЛИАЛ ТАШКЕНТСКОГО
УНИВЕРСИТЕТА ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ ИМЕНИ
МУХАММАДА АЛ-ХОРЕЗМИ
ФАКУЛЬТЕТ КОМПЬЮТЕРНОЙ ИНЖЕНЕРИИ
ИНДИВИДУАЛЬНЫЙ ПРОЕКТ
Тема: «Введение в разработку данных»
Выполнил(а): студент КИС 20-03 (А) Абилов Умиджон
Проверил(а): Олимжонова Саодат
Самарканд 2024
2
3
Содержание
Введение
Техническое задание
1. Теоретическая часть
1.1 Проектирование логической структуры базы данных методом
сущность-связь
1.2 Проектирование логической структуры базы данных методом
нормальных форм
1.3 Данные и ЭВМ
1.4 Концепция баз данных
1.5 Модели данных
1.6 Описание этапов проектирования
2. Практическая часть
2.1 Разработка инфологической модели
2.2 Разработка базы данных для хранения и обработки информации
2.3 Разработка программного приложения
Заключение
Литературы
Приложение 1
Приложение 2
4
Введение
В сегодняшнем технологическом мире все больше увеличивается
значительность информации в самом широком смысле этого слова и
связанных с ней информационных технологий. Для больших объемов
информации главным качеством является их структурированность, так как
именно от характера структуры данных зависит скорость обработки поиска
информации.
Базы данных - это совокупность сведений (о реальных объектах, процессах,
событиях или явлениях), относящихся к определенной теме или задаче,
организованная таким образом, чтобы обеспечить удобное представление
этой совокупности, как в целом, так и любой ее части. Базы данных всегда
были важнейшей темой при изучении информационных систем. Цель базы
данных - помочь людям и организациям вести учет определенных вещей.
Реляционная база данных представляет собой множество взаимосвязанных
таблиц, каждая из которых содержит информацию об объектах
определенного типа. Каждая строка таблицы включает данные об одном
объекте (например, клиенте, автомобиле, документе), а столбцы таблицы
содержат различные характеристики этих объектов атрибуты (например,
марки автомобилей).
База данных на сегодняшний день - это самый распространенный ”повод”
для написания программ. Все современные языки программирования
5
содержат в себе встроенные возможности для быстрого и удобного создания
СУБД (лидерами, на мой взгляд, сейчас является Delphi 5 и С++ Builder 5).
СУБД - это, конечно, нечто большее, чем просто набор структурированных
данных. СУБД можно назвать “умной” средой, с помощью которой можно
обрабатывать, искать, передавать, хранить данные. От качества СУБД
зависит эффективность работы с базой данных в целом. Современные СУБД
- это “высокоинтеллектуальные" системы, позволяющие работать не только с
базами данных, но и с базами знаний. Это направление, связанное с
накоплением, получением, сортировкой и использованием знаний, является
довольно новым. С понятием “база знаний“ тесно связанно понятие
искусственного интеллекта, что говорит об огромных масштабах работ,
которые потребуются провести для совершенствования сегодняшних СУБД,
так как искусственный интеллект - это новый горизонт в нашей
компьютерной эпохе. При работе баз данных и связанных с ними программ
обработки и поиска информации необходимо учитывать специфику
предметной области - одно из важнейших достоинств базы данных. Конечно,
здесь можно говорить о том, что уже давно существуют универсальные
формы для баз данных, универсальные СУБД, универсальный модуль
обработки данных. Но эта универсальность требует больших, (если не
огромных) затрат машинного времени и ресурсов, не говоря уж о стоимости
всего ПО. Поэтому чаще всего используют специализированные БД и СУБД.
В данной курсовой работе также будет создана специализированная база
данных для учёта товаров на складе магазина.
1. Теоретическая часть
1.1 Проектирование логической структуры базы данных методом
сущность-связь.
На этом этапе создаются подробные модели пользовательских представлений
данных предметной области. Затем они интегрируются в концептуальную
6
модель, которая фиксирует все элементы корпоративных данных,
подлежащих загрузке в базу данных. Эту модель называют концептуальной
схемой базы данных.
Средством моделирования предметной области на этапе концептуального
проектирования является модель «сущность-связь». Часто ее называют ERмоделью. В ней моделирование структуры данных предметной области
базируется на использовании графических средств - ER-диаграмм. В
наглядном виде они представляют связи между сущностями.
Основными понятиями ER-диаграммы являются сущность, атрибут,
связь.
Сущность представляет собой объект, информация о котором хранится в базе
данных. Сущность имеет экземпляры, отличающиеся друг от друга
значениями атрибутов и допускающие однозначную идентификацию.
Атрибут - это свойство сущности. Атрибут, который уникальным образом
идентифицирует экземпляры сущности, называется ключом. Может быть
составной ключ, представляющий комбинацию нескольких атрибутов. Связь
представляет взаимодействие между сущностями. Она характеризуется
мощностью, которая показывает, сколько сущностей участвует в связи.
Рассмотрим проектирование базы данных ГАИ. В ней могут быть
определены четыре сущности: сущность «водитель» - содержит
персональную информацию о водителях, сущность «автомобили» содержит информацию об автомобилях, сущность «нарушения» содержит о нарушениях правил дорожного движения, сущность
«взыскания» - содержит информацию о взысканиях с водителейнарушителей.
В рассматриваемой предметной области ГАИ можно выделить три связи.
Водитель
может
иметь
несколько
автомобилей,
а
автомобиль
принадлежит одному водителю, то создадим связь «имеет» между
таблицами «водитель» и «автомобиль». В этом случае связь 1 имеет тип
«один-ко-многим» (1:М). Так как каждый водитель обязательно имеет
7
автомобиль, а каждый автомобиль обязательно принадлежит водителю, то
класс принадлежности обеих сущностей является обязательным.
Водитель может получить несколько взысканий, взыскание применяется к
одному водителю, то создадим связь «получает» между таблицами «водитель»
и «взыскание». В этом случае связь 2 имеет тип «один-ко-многим» (1:М). Так
как каждый водитель не обязательно получает взыскание, а каждое взыскание
обязательно применяется к водителю, то класс принадлежности сущности
«водитель» необязательный, а сущности «взыскание» обязательный.
Одному и тому же нарушению могут соответствовать несколько
взысканий, взысканию соответствует единственное нарушение, то
создадим связь «соответствует» между таблицами «нарушение» и
«взыскание». В этом случае связь 3 имеет тип «один-ко-многим» (1:М). Так
как нарушению не обязательно соответствует взыскание, а каждому
взысканию
обязательно
соответствует
нарушение,
то
класс
принадлежности сущности «нарушение» необязательный, а сущности
«взыскание» обязательный.
Каждая из четырех сущностей приведенной ER-модели может быть
описана своим набором атрибутов. Первичные ключи для сущностей
выделим жирным шрифтом.
ER-модель в совокупности с наборами атрибутов сущностей может
служить примером концептуальной модели предметной области или
концептуальной схемы базы данных.
Водитель
Номер водительского удостоверения (НВУ)
Ф.И.О. (Ф.И.О.)
Адрес (АДР)
Телефон (ТЕЛ)
Автомобиль
Номер автомобиля (Н_АВТ)
Марка (МАР)
Модель (МОД)
Цвет (ЦВ)
Год выпуска (ГОД_В)
Дата регистрации в ГАИ (ДАТ_Р)
Нарушения
8
Код нарушения (КН)
Вид нарушения (ВИД_Н)
Штраф (ШТР)
Предупреждение (ПРЕД)
Срок лишения права управления автомобилем (СР_Л)
Взыскания
Код нарушения (КН)
Дата и время нарушения (ДАТ_Н)
Номер водительского удостоверения (НВУ)
Район совершения нарушения (Р_Н)
Размер штрафа (РАЗМ_ШТР)
Оплачен штраф или не оплачен (ОПЛ_ШТР)
Срок лишения права управления автомобилем (СР_Л)
Базовая величина (Б_В)
Личный номер инспектора ДПС (Л_НОМ)
1.2 Проектирование логической структуры базы данных методом
нормальных форм.
Концептуальные модели позволяют более точно представить предметную
область, чем реляционные и другие более ранние модели. Но в настоящее
время существует немного систем управления базами данных,
поддерживающих эти модели. На практике наиболее распространены
системы, реализующие реляционную модель. Поэтому необходим метод
перевода концептуальной модели в реляционную. Такой метод
основывается на формировании набора предварительных таблиц из ERдиаграмм.
Для каждой сущности создается таблица. Причем каждому атрибуту
сущности соответствует столбец таблицы.
Правила генерации таблиц из ER-диаграмм опираются на два основных
фактора - тип связи и класс принадлежности сущности. Изложим их.
. Если связь типа 1:1 и класс принадлежности обеих сущностей является
обязательным, то необходима только одна таблица. Первичным ключом
этой таблицы может быть первичный ключ любой из двух сущностей.
. Если связь типа 1:1 и класс принадлежности одной сущности является
обязательным, а другой - необязательным, то необходимо построить
таблицу для каждой сущности. Первичный ключ сущности должен быть
первичным ключом соответствующей таблицы. Первичный ключ
сущности, для которой класс принадлежности является необязательным,
добавляется как атрибут в таблицу для сущности с обязательным классом
принадлежности.
9
. Если связь типа 1:1 и класс принадлежности обеих сущностей является
необязательным, то необходимо построить три таблицы - по одной для
каждой сущности и одну для связи. Первичный ключ сущности должен
быть первичным ключом соответствующей таблицы. Таблица для связи
среди своих атрибутов должна иметь ключи обеих сущностей.
. Если связь типа 1:М и класс принадлежности сущности на стороне М
является обязательным, то необходимо построить таблицу для каждой
сущности. Первичный ключ сущности должен быть первичным ключом
соответствующей таблицы. Первичный ключ сущности на стороне 1
добавляется как атрибут в таблицу для сущности на стороне М.
. Если связь типа 1:М и класс принадлежности сущности на стороне М
является необязательным, то необходимо построить три таблицы - по
одной для каждой сущности и одну для связи. Первичный ключ сущности
должен быть первичным ключом соответствующей таблицы. Таблица для
связи среди своих атрибутов должна иметь ключи обеих сущностей.
. Если связь типа М:N, то необходимо построить три таблицы - по одной
для каждой сущности и одну для связи. Первичный ключ сущности
должен быть первичным ключом соответствующей таблицы. Таблица для
связи среди своих атрибутов должна иметь ключи обеих сущностей.
На ER-диаграмме связи 1:М, представленной на рисунок 4, класс
принадлежности сущностей «водитель», «автомобиль» является
обязательным.
Анализ состава атрибутов полученных таблиц A, B, C, D, E, F показывает,
что таблица C является составной частью таблицы А, таблица F составной частью таблицы D. Поэтому таблицы C, F можно исключить из
рассмотрения. Оставшиеся таблицы A, B, D, E можно связать
посредством связи первичных и вторичных ключей. В результате
получим реляционную модель для ER-модели предметной области ГАИ.
Реляционная база данных считается эффективной, если она обладает
приведенными ниже характеристиками:
1) Минимизация избыточных данных;
2) Минимальное использование отсутствующих значений (Nullзначений);
3) Предотвращение потери информации.
В базе данных присутствует избыточность, если одни и те же данные
находятся в нескольких местах. Минимизировать избыточность данных
позволяет процесс, называемый нормализацией таблиц. Методику
нормализации таблиц разработал американский ученый А.Ф. Кодд в 1970
году. Ее суть сводится к приведению таблиц к той или иной нормальной
10
форме. Были выделены три нормальные формы - 1НФ, 2НФ, 3НФ. Позже
стали выделять нормальную форму Бойса-Кодда (НФБК), а затем 4НФ и
5НФ. Каждая последующая нормальная форма вводит определенные
ограничения на хранимые в базе данные.
Реляционная база данных считается эффективной, если все ее таблицы
находятся как минимум в 3НФ. Приведение к 3НФ осуществляется, если
есть основание для этого.
Определение 1НФ: таблица находится в 1НФ, если все ее поля содержат
только простые неделимые значения. Все таблицы удовлетворяют 1НФ,
так как все они содержат только простые неделимые значения.
Определение 2НФ: таблица находится во 2НФ, если она удовлетворяет
требованиям 1НФ и неключевые поля функционально полно зависят от
первичного ключа. В полученной базе данных все поля каждой таблицы
функционально полно зависят от своих первичных ключей.
Определение 3НФ: таблица находится в 3НФ, если она удовлетворяет
требованиям 2НФ и не содержит транзитивных зависимостей.
Транзитивной зависимостью называется функциональная зависимость
между неключевыми полями. Все созданные таблицы находятся в 3НФ.
Таким образом, реляционная модель предметной области ГАИ после
нормализации таблиц остается прежней.
1.3 Данные и ЭВМ
Применение ЭВМ для введения и обработки данных обычно приводит к еще
большему разделению данных и интерпретации. ЭВМ имеет дело главным
образом с данными как таковыми. Большая часть интерпретирующей
информации вообще не фиксируется в явной форме. Существует, по крайней
мере, две исторические причины, по которым применение ЭВМ привело к
отделению данных от интерпретации. Во-первых, ЭВМ не обладали
достаточными возможностями для обработки текстов на естественном языке
- основном языке интерпретации данных. Во-вторых, стоимость памяти ЭВМ
была первоначально весьма велика. Память использовалась для хранения
самих данных, а интерпретация традиционно возлагалась на пользователя.
11
Жесткая зависимость между данными и использующими их программами
создает серьезные проблемы во введении данных и делает использование их
менее гибкими.
Нередки случаи, когда пользователи одной и той же ЭВМ создают и
используют в своих программах разные наборы данных, содержащие
сходную информацию. Иногда это связано с тем, что пользователь не знает
(либо не захотел узнать), что в соседней комнате или за соседним столом
сидит сотрудник, который уже давно ввел в ЭВМ нужные данные. Чаще
потому, что при совместном использовании одних и тех же данных возникает
масса проблем. Разработчики прикладных программ (написанных, например,
на Бейсике, Паскале или Си) размещают нужные им данные в файлах,
организуя их наиболее удобным для себя образом. При этом одни и те же
данные могут иметь в разных приложениях совершенно разную организацию
(разную последовательность размещения в записи, разные форматы одних и
тех же полей и т.п.). Обобществить такие данные чрезвычайно трудно:
например, любое изменение структуры записи файла, производимое одним
из разработчиков, приводит к необходимости изменения другими
разработчиками тех программ, которые используют записи этого файла.
1.4 Концепция баз данных
Активная деятельность по отысканию приемлемых способов обобществления
непрерывно растущего объема информации привела к созданию в начале 60х годов специальных программных комплексов, называемых "Системы
управления базами данных" (СУБД).
Основная особенность СУБД - это наличие процедур для ввода и хранения не
только самих данных, но и описаний их структуры. Файлы, снабженные
описанием хранимых в них данных и находящиеся под управлением СУБД,
стали называть банками данных, а затем "Базами данных" (БД).
12
1.5 Модели данных
Имеются две основные модели данных: инфологическая модель и
даталогическая модель.
Инфологическая модель отображает реальный мир (предметную область) в
некоторые понятные человеку концепции, полностью независимые от
параметров среды хранения данных. Существует множество подходов к
построению таких моделей: графовые модели, семантические сети, модель
"сущность-связь" и т.д. Наиболее популярной из них оказалась модель
"сущность-связь". Инфологическая модель должна быть отображена в
компьютеро-ориентированную даталогическую модель, "понятную" СУБД. В
процессе развития теории и практического использования баз данных, а
также средств вычислительной техники создавались СУБД,
поддерживающие различные даталогические модели. Сначала стали
использовать иерархические даталогические модели. Простота организации,
наличие заранее заданных связей между сущностями, сходство с
физическими моделями данных позволяли добиваться приемлемой
производительности иерархических СУБД на медленных ЭВМ с весьма
ограниченными объемами памяти. Но, если данные не имели древовидной
структуры, то возникала масса сложностей при построении иерархической
модели и желании добиться нужной производительности.
В конце 60-х годов появились СУБД на основе инвертированных файлов,
отличающиеся простотой организации и наличием весьма удобных языков
манипулирования данными. Однако такие СУБД обладают рядом
ограничений на количество файлов для хранения данных, количество связей
между ними, длину записи и количество ее полей. Физическая организация
данных оказывает основное влияние на эксплуатационные характеристики
БД. Разработчики СУБД пытаются создать наиболее производительные
физические модели данных, предлагая пользователям тот или иной
инструментарий для поднастройки модели под конкретную БД.
13
1.6 Описание этапов проектирования.
Инфологическая модель БД.
Этапом инфологической модели является этап проектирования БД на
котором составляется инфологическая модель и схемы взаимосвязи можно
определить, что данный этап является первым.
Под инфологической моделью понимают описание предметной области,
выполненное с использованием специальных языковых средств, не
зависящих от используемых в дальнейшем программных средств (это по
существу блок-схема алгоритма создания базы данных).
Требования к инфологической модели:
адекватное отображение предметной области;
непротиворечивость;
должна отражать взгляды и потребности всех пользователей системы;
однозначная трактовка моделей;
модель должна быть конечной;
модель должна быть легко расширяемой, то есть иметь возможность ввода
новых (удаления) данных без изменения ранее определенных;
должна обладать свойствами композиции и декомпозиции (укреплять базу
данных или расщеплять);
должна быть легко реализуемой на ЭВМ;
должна быть независимой от оборудования и языков организации базы
данных на ЭВМ.
Цель инфологического моделирования - обеспечение наиболее естественных
для человека способов сбора и представления той информации, которую
предполагается хранить в создаваемой базе данных.
Основными конструктивными элементами инфологических моделей
являются сущности, связи между ними и их свойства (атрибуты).
14
Сущность - любой различимый объект (объект, который мы можем отличить
от другого), информацию о котором необходимо хранить в базе данных.
Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д.
Необходимо различать такие понятия, как тип сущности и экземпляр
сущности. Понятие тип сущности относится к набору однородных
личностей, предметов, событий или идей, выступающих как целое.
Экземпляр сущности относится к конкретной вещи в наборе. Например,
типом сущности может быть ГОРОД, а экземпляром - Москва.
Атрибут - поименованная характеристика сущности. Его наименование
должно быть уникальным для конкретного типа сущности, но может быть
одинаковым для различного типа сущностей (например, ЦВЕТ может быть
определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.).
Атрибуты используются для определения того, какая информация должна
быть собрана о сущности.
Ключ - минимальный набор атрибутов, по значениям которых можно
однозначно найти требуемый экземпляр сущности. Минимальность означает,
что исключение из набора любого атрибута не позволяет идентифицировать
сущность по оставшимся.
Связь - ассоциирование двух или более сущностей. Если бы назначением
базы данных было только хранение отдельных, не связанных между собой
данных, то ее структура могла бы быть очень простой. Однако одно из
основных требований к организации базы данных - это обеспечение
возможности отыскания одних сущностей по значениям других, для чего
необходимо установить между ними определенные связи. А так как в
реальных базах данных нередко содержатся сотни или даже тысячи
сущностей, то теоретически между ними может быть установлено более
миллиона связей. Наличие такого множества связей и определяет сложность
инфологических моделей. Связь между объектами и характеризующими его
свойствами изображается в виде линий, соединяющих обозначение объекта и
его свойств. Свойства могут быть единичными или множественными.
15
Обычно для изображения связей между объектом и единичным свойством
используется единичная стрелка, а для множественных свойств - двойная
стрелка. Свойства могут быть статическими и динамическими.
Даталогическая модель БД.
Этап проектирования БД на котором создается датологическая модель
называется этапом даталогического проектирования. Даталогическая модель
является моделью логического уровня и представляет собой отображение
логических связей между элементами данных. Эта модель строится в
единицах допустимых конкретной СУБД. Описание логической структуры с
помощью средств СУБД называется схемой. Так как это осуществляется с
помощью конкретной СУБД, то модели должны быть описаны на языке
описания данных этой СУБД. Такое описание и называют даталогической
моделью данных.
Физическая модель БД.
Для привязывания даталогической модели к среде хранения используется
модель данных физического уровня. Эта модель определяет используемые
запоминающие устройства, способы представления данных в среде хранения.
Модель физического уровня строится также с учетом возможностей,
предоставленных СУБД. Таким образом, нужные данные отыскиваются
СУБД на внешних запоминающих устройствах по физической модели
данных.
2. Практическая часть
2.1 Разработка инфологической модели.
По окончании проведенного анализа предметной области можно перечислить
наименование имеющегося товара: номер магазина в котором товар имеется,
код товара, количество товара, качество, номер полки на которой находится
данный товар, а также номер стеллажа.
16
Начнем проектирование базы данных с построения инфологической модели.
Сущностью в инфологической модели является код необходимого товара,
номе магазина являются атрибутами сущности. Идентификатором сущности
является наименование товара, позволяющий однозначно идентифицировать
объект.
На рис.1 представлена полученная инфологическая модель.
Задание: склад магазинов.
База данных состоит из двух таблиц.
1.Таблица “Склад” - место нахождение товаров на складе.
2.Таблица “Товары" - качественные и количественные характеристики
товаров.
Рис. 1: Инфологическая модель
17
2.2 Разработка базы данных для хранения и обработки информации.
Отталкиваясь от инфологической модели, строим даталогическую модель
данных, т.е. мы берём элементы инфологической модели и формируем их в
отдельные таблицы (для каждой сущности отдельно).
Схемы данных для хранения информации о магазинах
Схема данных для хранения информации о складе:
Таблица 1:
№
Наименование
Название
Тип
1
N_Zd
Номер здания
Числовой
2
N_St
Номер стеллажа
Числовой
3
N_P
Номер полки
Числовой
4
Kod
Код товара
Числовой
Размерность
Схема данных для хранения информации о товарах:
Таблица 2:
№
Наименование
Название
Тип
Размерность
1
Kod
Код товара
Числовой
2
Cena
Цена товара
Числовой
3
Kol
Количество (шт.)
Числовой
4
Naim
Наименование
Символьный
25
5
Kach
Качество товара
Символьный
8
Рассмотрим связи таблиц.
18
.
Сложная связь, которая предназначена для определения характеристик
товара. Со стороны таблицы “ склад" эта связь является множественной, так
как один и тот же товар может находиться в разных местах на складе. Со
стороны таблицы, товары - это связь является множественной, так как на
одной полке - минимальной единицы указано местоположение - может
находиться более одного наименования товаров. С точки зрения
программной реализации данной связи является очень сложной.
2.Эта связь является простой (однозначной) с обеих сторон. Действительно,
определенное здание и стеллаж могут иметь только одни координаты, и
никакие другие.
Прежде, чем начать строить приложения, работающие с базами данных, надо
иметь сами базы данных. Вместе с BDE и Borland C++Builder поставляется
программа Database Desktop, которая позволяет создавать таблицы баз
данных некоторых СУБД, задавать и изменять их структуру. Для каждого
поля создаваемой таблицы, прежде всего, указывается имя (Field Name) идентификатор поля. Он может включать до 25 символов и не может
начинаться с пробела (но внутри пробелы допускаются). Затем надо выбрать
тип (Type) данных этого поля. Для этого перейдем в раздел Type поля и
щелкнем правой кнопкой мыши. В появившемся списке доступных типов, из
которого мы можем выбрать необходимый.
Разные СУБД по-разному организуют и хранят базы данных. СУБД Paradox
используют для каждой таблицы отдельный файл. В этом случае база данных
- это каталог, в котором хранятся файлы таблиц. Для создания такого
каталога - базы данных необходимо запустить инструмент BDE Administrator
(Borland Database Engine) из меню Пуск| Программы| C++Builder. В левой
половине окна расположен список существующих баз данных. Создадим
новые базы данных. Для этого с главного меню зададим команду Object |
New. На данную команду BDE выведет окно. Переименовав название
STANDART на BOLNIE, и задав путь, где располагаются таблицы базы
данных (Path - обычно это каталог Database Desktop\Workdir) закончим
19
работу с BDE. Итак, мы можем создавать таблицы для базы данных Товаров.
Загрузим инструментарий Database Desktop. Через главное меню составим
команду File | New | Table. На запрос системы выберем платформу таблиц
СУБД Paradox v.7. В открывшееся окно введем структуру таблицы Sklad. db.
Рис. 2: Ввод данных в таблицу
Введем данные сначала в таблицу. Для этих целей можно использовать
горячую кнопку "Open Table". В открывшуюся таблицу можно внести
данные о наименованиях. Для этих целей на панели инструментов
расположена кнопка редактирования (Edit Data), "нажатие" которой
добавляет новую запись с данными по умолчанию, готовую для
редактирования. Введем наименования товаров. После этого закроем окно с
таблицей.
Аналогичными действиями создадим таблицу Tovar. db. В этой таблице
первичным ключом установим код товара (поле Tovar).
Выберем пункт меню Table|Restructure, позволяющий изменять свойства
таблицы, при этом окно аналогично окну создания таблицы. Выберем в
спадающем списке пункт Secondary Indexes. Нажав кнопку "Define." откроем
окно, в котором слева расположены поля таблицы, а справа пустое окно, в
20
которое заносятся поля, по которым создается индекс. Вторичными
индексами обозначим s1-Cena, s2-Kol, s3-Naim, s4-Kach.
Далее вводим данные в таблицу.
Рис. 3: Ввод данных в таблицу
2.3 Разработка программного приложения
Язык SQL (Structured Query Language) - язык структурированных запросов)
был создан Microsoft в конце 70-ых годов и получил через некоторое время
широкое распространение. Он позволяет формировать весьма сложные
запросы к базам данных.
Запрос - это вопрос к базе данных, возвращающий запись или множество
записей, удовлетворяющих вопросу.
C++Builder позволяет приложению при помощи запросов SQL использовать
данные:
Таблиц PARADOX и dBase используется синтаксис локального SQL.
21
Локального сервера InterBase - полностью поддерживается
соответствующий синтаксис.
Удаленных серверов SQL через драйверы SQL Links.
В Borland C++Builder имеется специальный компонент набора данных
Query, являющийся аналогом Таblе, но позволяющий работать с SQL
. Создание простого приложение. Подключение к форме компонентов
DataSource, Query, DBGrid, причем в качестве базы данных используем
таблицы созданные в лабораторной работе №2. Выведение в сетку таблицы
(DBGrid).
Откроем новое приложение (File/New/Application) Borland C++Builder,
перенесём на форму компонент Query со страницы библиотеки Data Access
(BDE) и установим его свойство DatabaseName равным имени созданной
нами базы данных (Sklad). Поместим на форму компонент DataSource со
страницы Доступ к данным (Data Access). Его свойству Name соответствует
Datasource1, а свойству DataSet задайте Queryl. Поместим также на форму
компонент DBGrid (Управление данными - Data Control) и в его свойстве
DataSource зададим DataSourcel
Теперь наше приложение для экспериментов с языком SQL готово.
Операторы SQL можем писать в свойстве SQL компонента Queryl, а чтобы
увидеть результаты выполнения написанного оператора, надо будет
устанавливать значение свойства Active компонента Queryl в true. Это надо
будет делать после записи каждого нового оператора. В свойстве SQL
запишем оператор: Select Kod as Код, N_St as Ном_стеллажа, N_P as
Номер_полки, N_Zd as Номер_здания from Sklad
Установим свойство Active в true и убедимся, что все работает нормально: в
DBGridI должно отобразиться содержимое таблицы Sklad. Добавив
компоненту DBNavigator и установив свойство DataSource равным
DataSource1 запустим на выполнение полученное приложение.
22
Создадим другую аналогичную цепочку, перенеся на форму компоненты
Query2, DataSource2. DBGrid2, и связав ее с таблицей Tovar. db запросом в
компоненте:
Select * from Tovar
в компоненте Qnery2. Установим свойство Active компонента Query2 в true
и в DBGrid2 должно отобразиться содержимое таблицы Tovar. Запустим
приложение и убедимся, что оно работает, причем таблицы независимы.
Теперь давайте, свяжем эти таблицы. Делается это следующим образом.
Изменим текст запроса в свойстве SQL вспомогательного компонента набора
данных Query2 на: Select Kod as Код, Cena as Цена, Kol as Наименование,
Naim as from Tovar.
Рис. 4: Страница поиска
В этом запросе мы указываем условие отбора: значение поля Koд должно
быть равно параметру Коd. В данном случае не надо определять этот
параметр с помощью редактора параметров, вызываемого из свойства
Params компонента Query2. Вместо этого в свойстве DataSource
компонента Query2 надо сослаться на: DataSourcel - источник данных,
связанный с таблицей Sklad. Это скажет приложению, что оно должно взять
значения параметра Номер_здания из текущей записи этого источника
23
данных. Таким образом, вспомогательная таблица, запрашиваемая в Query2,
оказывается связанной с головной таблицей, запрашиваемой в Queryl
Добавив компоненты визуализации Label (свойство Caption) DBText
(свойства DataSource=DataSource1, DataField = соответствуюшее поле)
получим конечную форму приложении.
Рис. 5: Страница редактирования и данных
На странице "Поиск и Фильтрация" размещаем: по одному компоненту
DBGrid, DBNavigator, 1 компонентов Edit, 2 компонент ComboBox и 1
компонент RadioGroup.
Для компоненты RadioGroup установлены такие свойства:
Caption=Фильтрация, Items=Все, Здание, Columns=2. В событии OnClick
компонента RadioGroup записываем код который будет осуществлять
фильтрацию.
В свойствах Items для компонента ComboBox1 (CB1) перечислены все
здания. Свойству ItemIndex присвоено значение 0. Для каждой компоненты
Edit размещены компоненты Label с соответствующими надписями. Для
компоненты Edit1 в событии OnChange записываем соответствующий код
который будет осуществлять поиск. Использованные также свойства Font и
Color придали странице вид. После выполнения всех указанных действий и
создания программного кода на этой странице компоненты PageControl
будет происходить поиск и фильтрование данных.
24
Для некоторых компонент в свойстве Font, Color установлены определенные
цвета фоновой заливки, шрифта для большей привлекательности таблицы.
Рис. 6: Страница фильтрация и поиск
25
Заключение
Данная курсовая работа посвящена разработке базы данных ”Магазин” для
магазинов. Она заключена в автоматизации ведения учета. Такого рода
программы очень распространены на сегодняшний день.
Наша программа является достаточно специализированной (в том смысле,
что посвящена, в основном, определенное место расположения искомого
товара и предназначении тех магазинов или сети магазинов, у которых
имеется достаточно большой склад товаров, чтобы его можно было бы
разбить на цеха и составить его план.
С помощью этой программы можно увидеть, где именно расположен склад с
искомым товаром.
В процессе выполнения курсовой работы я получила навыки работы с
программой Borland C++ Builder 6. Она актуальна в наше время, многие
информатики-экономисты используют ее в своей практической работе.
26
Литературы
1. Диго С.М. Проектирование баз данных. М.: Финансы и статистика, 2002 г.
2. Марков А.С. Базы данных. Введение в теорию и методологию. М.:
Финансы и статистика, 2002 г.
. Мейер Д. Теория реляционных баз данных. М., 1987.608 с., ил.
. Тихонов А.Ф., Тихонова Л.Н. Visual FoxPro 5.0. М., 1997.466 с.
. Архангельский А.Я. Программирование в C++ Builder 6 - М: ЗАО
"Издательство БИНОМ" 2002 г.
. Архангельский А.Я. Интегрированная среда разработки C++ Builder 5 - М:
ЗАО "Издательство БИНОМ", 2000 г.
. Архангельский А.Я. Работа с локальными базами данных в C++ Builder 5 М: ЗАО "Издательство БИНОМ", 2000 г.
. Архангельский А.Я. Язык SQL в C++ Builder 5 - М: ЗАО "Издательство
БИНОМ", 2000 г.
27
Приложение 1
Листинг программы
// --------------------------------------------------------------------------#include <vcl. h>
#pragma hdrstop
#include "Unit1. h"
// --------------------------------------------------------------------------#pragma package (smart_init)
#pragma resource "*. dfm"*Form1;
// --------------------------------------------------------------------------__fastcall TForm1:: TForm1 (TComponent* Owner)
: TForm (Owner)
{
}
// ---------------------------------------------------------------------------__fastcall
TForm1:: RGFClick (TObject *Sender)
{(RGF->ItemIndex==0)->Filtered=False;
{Table1->Filter="N_Zd='"+CB1->Text+"'";->Filtered=True; }
}
// ---------------------------------------------------------------------------__fastcall
TForm1:: CB1Change (TObject *Sender)
{ if (RGF->ItemIndex==0)->Filtered=False;
{Table1->Filter="N_Zd='"+CB1->Text+"'";->Filtered=True; }
}
// ---------------------------------------------------------------------------__fastcall
TForm1:: Edit1Change (TObject *Sender)
{->FindNearest (&TVarRec (Edit1->Text),0);
}
// --------------------------------------------------------------------------28
Приложение 2
Результат работы программы.
Рис. 1: Результат работы поиска
Рис. 2: Результат работы редактирование данных
29
Рис. 3: Результат работы фильтрация и поиск
30
