Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
delphi programs training tasks
Typology: Study Guides, Projects, Research
1 / 51
This page cannot be seen from the preview
Don't miss anything!
Научный руководитель: Кузнецов В.В. преподаватель Кафедры компьютерных технологий Туймазы 2022
Предмет исследования – автоматизация паспортного стола в сфере жилищно-коммунальных услуг. Целью курсовой работы является автоматизации паспортного стола в сфере жилищно-коммунальных услуг. Задачи курсовой работы состоят в следующем:
1.1 Виды жилищно-управляющих организаций База данных - поименная совокупность структурированных данных, относящихся к определенной предметной области. Под предметной областью принято понимать часть реального мира, подлежащую изучению для организации управления и автоматизации (предприятия, организации). Анализ предметной области позволяет определить, какие данные содержатся в БД. Пользователями БД могут быть различные прикладные программы, программы-комплексы, а также специалисты предметной области, которые называются конечными пользователями. Модель предметной области - это наши знания о предметной области. Знания могут быть как в виде неформальных знаний в мозгу эксперта так и выражены формально при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в компании и т.п. Опыт
привлеченных ими, направленная на обеспечение благоприятных и безопасных условий проживания граждан, надлежащего содержания общего имущества в многоквартирном доме, решения вопросов пользования общим имуществом, а также предоставления коммунальных услуг гражданам, проживающим в таком доме. Управляющая компания – это организация, которая имеет право управлять имуществом своих клиентов посредством индивидуального доверительного управления, паевого или акционерного фонда. Помимо этого, управляющая компания занимается управлением пенсионными резервами негосударственных пенсионных фондов. Деятельность управляющих компаний подлежит обязательному лицензированию Федеральной службой по финансовым рынкам. База данных - поименная совокупность структурированных данных, относящихся к определенной предметной области. Под предметной областью принято понимать часть реального мира, подлежащую изучению для организации управления и автоматизации (предприятия, организации). Анализ предметной области позволяет определить, какие данные содержатся в БД. Пользователями БД могут быть различные прикладные программы, программы-комплексы, а также специалисты предметной области, которые называются конечными пользователями. Модель предметной области - это наши знания о предметной области. Знания могут быть как в виде неформальных знаний в мозгу эксперта так и выражены формально при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в компании и т.п. Опыт показывает, что текстовый способ представления модели предметной области крайне неэффективен. Гораздо более информативными и полезными при разработке баз данных являются описания предметной области, выполненные при помощи специализированных графических нотаций. Данная база данных предназначена для учреждений, занимающихся
принятие абитуриентов на поступление в среднее общеобразовательные учреждения. БД позволяет вести учет всех абитуриентов, хранит полную информацию о каждом абитуриенте (ФИО, дата рождения, адрес, паспорт, аттестат, и т.п.), позволяет вести учет абитуриентов, которые когда-либо обращались в какое - либо общеобразовательное учреждение. Программа позволяет также распечатать и просмотреть отчет по всем параметрам, интересующим как руководителям учреждения (информация об абитуриентов, полный отчет по всем таблицам, выборка по датам поступлений), так и на какую специальность (кафедра, тип специальности, план обучения); это позволяет вести отчетность на бумаге. В БД хранится информация о каждом абитуриенте, о каждом специальности. Существует возможность хранения не только основной и самой необходимой информации, но и примечаний, уточнений, фотографий абитуриентов. Существует один, на первый взгляд, недостаток, который при постоянном использовании БД характеризует себя с положительной стороны: в данной БД информация об абитуриентах исходном состоянии является независимой. Связь абитуриента, который подает на конкретную специальность отслеживается лишь в процессе оформления документов, после чего успешно хранится в базе. Проектирование базы данных – одна из наиболее сложных и ответственных задач, связанных с созданием информационной системы. В результате её решения должны быть определены: содержание БД, эффективный для всех её будущих пользователей способ организации данных и инструментальные средства управления данными. Проектируемая база данных должна обеспечивать: − хранение всей необходимой информации; − возможность получения данных по всем необходимым запросам; − сокращение избыточности и дублирования данных;
На третьем этапе производится выбор СУБД. Теоретически при выборе СУБД нужно принимать во внимание десятки факторов. Но практически разработчики руководствуются лишь собственной интуицией и несколькими наиболее важными критериями, к которым, в частности, относятся: − тип модели данных, которую поддерживает данная СУБД, её адекватность потребностям рассматриваемой предметной области; − характеристики производительности системы; − запас функциональных возможностей для дальнейшего развития ИС; − степень оснащённости системы инструментарием для персонала администрирования данными; − удобство и надежность СУБД в эксплуатации; − стоимость СУБД и дополнительного программного обеспечения. После того как выбор СУБД завершён, необходимо приступить к следующему, четвертому этапу, – проектированию даталогической модели базы данных. При формировании даталогической схемы каждая из определённых в концептуальной схеме сущностей отображается в таблицу, которая является одним отношением. При этом следует учитывать ограничения на размер таблиц, накладываемые конкретной СУБД. 1.2. Проектирование базы данных. Описание логической структуры Проектирование базы данных — процесс создания схемы базы данных и определения необходимых ограничений целостности. Основные задачи: Обеспечение хранения в БД всей необходимой информации. Обеспечение возможности получения данных по всем необходимым запросам. Сокращение избыточности и дублирования данных. Обеспечение целостности базы данных.
Проектирование базы данных осуществляется в три этапа:
пользователи не подтвердят, что предложенная им модель адекватно отображает их личные представления. Процедуры логического проектирования Цель этапа логического проектирования - преобразование концептуальной модели на основе выбранной модели данных в логическую модель, не зависимую от особенностей используемой в дальнейшем СУБД для физической реализации базы данных. Для ее достижения выполняются следующие процедуры.
Перечень транзакций определяется действиями пользователей в предметной области. Используя ER-модель, словарь данных и установленные связи между первичными и внешними ключами, производится попытка выполнить все необходимые операции доступа к данным вручную. Если какую-либо операцию выполнить вручную не удается, то составленная логическая модель данных является неадекватной и содержит ошибки, которые надо устранить. Возможно, они связаны с пропуском в модели сущности, связи или атрибута.
Рис.2 Логическая модель БД Таким образом, после мы спроектировали базу данных для фирмы, построили логическую структуру и модель, для дальнейшего использования в приложении. 1.3. Инфологическая модель БД входящая в программу Инфологическое проектирование прежде всего связано с попыткой представления семантики, то есть смыслового содержания, предметной области в модели БД. Реляционная модель данных в силу своей простоты и лаконичности не позволяет отобразить семантику, то есть смысл предметной области остается за рамками реляционной модели. Ранние теоретико- графовые модели в большей степени, чем реляционная модель, отображали семантику предметной области. Они в явном виде определяли иерархические связи между объектами предметной области. Проблема представления семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести модель «сущность—связь», предложенную Ченом (Chen) в 1976 году, семантическую модель данных, предложенную Хаммером (Hammer) и Мак- Леоном (McLeon) в 1981 году, функциональную модель данных Шипмана
(Shipman), также созданную в 1981 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только первая. И в настоящий момент именно модель Чена «сущность—связь», или «Entity Relationship», стала фактическим стандартом при инфологическом моделировании баз данных. Общепринятым стало сокращенное название ER-модель, большинство современных CASE- средств содержат инструментальные средства для описания данных в формализме этой модели. Кроме того, разработаны методы автоматического преобразования проекта БД из ER-модели в реляционную, при этом преобразование выполняется в даталогическую модель, соответствующую конкретной СУБД. Все CASE-системы имеют развитые средства документирования процесса разработки БД, автоматические генераторы отчетов позволяют подготовить отчет о текущем состоянии проекта БД с подробным описанием объектов БД и их отношений как в графическом виде, так и в виде готовых стандартных печатных отчетов, что существенно облегчает ведение проекта. После того как закончено исследование предметной области и детально поставлена задача проектирования можно переходить ко второму этапу, на котором проектируется база данных. На этом этапе используются формальные модели данных, в которые нужно преобразовать инфологическую модель. Такие модели, непосредственно используемые в базах данных, называются даталогическими. На рис.1 показаны три вида даталогических моделей: иерархические, сетевые и реляционные. Иерархическая модель имеет древовидную структуру. Каждая ветвь в такой структуре имеет одну родительскую ветвь и много дочерних. Примерами иерархических систем служат завод, система каталогов с файлами в ЭВМ. Завод состоит из цехов, цеха из участков, участки из станков с рабочими. В иерархической системе элементы одного уровня не связаны непосредственно между собой. В ней нельзя непосредственно указать, что
Сущность состоит из множества экземпляров, обладающих одинаковым набором свойств. Совокупность свойств, необходимая для отличия одного экземпляра от других, называется идентификатором сущности. Рассмотрим подробно, какими бывают сами сущности, их свойства и связи. В литературе часто вместо термина свойство сущности используют атрибут сущности. Но термин атрибут отношения (колонка, столбец таблицы) применяют в реляционной модели. При одновременном применении обеих моделей может возникнуть путаница. Виды сущностей бывают сильными и слабыми, делятся на тип и подтип. Слабая сущность в контексте решаемой задачи не может существовать без сильной. Например, в вузе студент обязательно входит в группу, т.е. сущность студент не может существовать без сущности группа. Сущность деталь не может существовать без сущности изделие, а сущность сотрудник - без сущности отдел. Если часть экземпляров сущности обладает дополнительными по отношению к другим экземплярам свойствами, то эту часть выделяют в подтип. На рис. 6 сущность студент является подтипом типа житель города, а сущность программист - подтипом типа сотрудник. Между типом и подтипом связь 1:1, но эта связь неполная, так как не каждому экземпляру типа соответствует экземпляр подтипа. Связи между сущностями
