Entity-Relationship Model AI Usage

Name of AI service/solution that was used

Name: OpenAI Codex / ChatGPT

URL: ​https://chatgpt.com/

Type of service/subscription: AI assistant used through an OpenAI account.

Final result

Diagram:

Model description:

The final result is ERModel_v08 for the BEST Skopje Hub information system. The model represents students, members and membership stages, organizational functions, activity sessions, event editions, event sessions, applications, core team functions, companies, attendance/RSVP for activity sessions, absence announcements, volunteering, mentorship, required attendance, and cooperation with companies.

My conversations with AI models, just like now, are usually for challenging my own way of thinking about the project and debating possible inconsistencies thoroughly.

The AI tool was used only after an initial ER model had already been created. It was used to review the model, point out missing or unclear parts, explain possible modeling alternatives, help choose between alternatives, and help write the textual data requirements in TracWiki notation. The final modeling decisions were made by me.

Entire AI usage log

Prompt 1: Can you tell me if the ER model fulfills my requirements and if not, what is missing, and what is redundant?

AI response 1: The AI reviewed the initial ER model using the project description for BEST Skopje Hub. It identified possible issues and unclear areas, including attendance scope, core team membership, BOMBA applications, application review data, eligibility rules, member specializations, assemblies, RSVP placement, and the similarity between ActivitySessions and EventSessions.

Prompt 2: I responded to the AI's suggestions and clarified that attendance checking for EventEditions and EventSessions is not needed, core team membership is implied by accepted applications, main organiser is a CoreTeamFunction, application review data is unnecessary, events are only for UKIM students, assemblies are out of scope, board member should be treated as a role, and RSVP should be tracked at activity session level.

AI response 2: The AI reconsidered the earlier comments based on my clarifications. It explained which suggestions were no longer necessary, which parts could remain business logic instead of ER model elements, and which parts still needed attention.

Prompt 3: How could event/session eligibility be modeled in the ER model anyway? I also said I did not understand the AI's question.

AI response 3: The AI explained that eligibility means who is allowed to attend, RSVP, or apply, for example public, members-only, full-members-only, alumni-only, or board-only. It explained that this does not need to be modeled if it is fixed business logic, but could be modeled with attributes or a relationship to membership stages if the system needs configurable eligibility.

Prompt 4: I'm confused about the relationship between FullMembers and OrganizationalFunctions. Should it be N:M or 1:N or N:1?

AI response 4: The AI explained that the relationship should be modeled as N:M because one full member can hold multiple organizational functions over time and the same organizational function can be held by different full members in different mandates.

Prompt 5: Should valid_from and valid_to dates be added? I thought mandate implies that.

AI response 5: The AI explained that if the project only needs to know the mandate, then the mandate attribute is enough. It also explained that valid_from and valid_to would only be needed if exact dates of holding a function have to be tracked.

Prompt 6: All relationships should be named. All attributes must have different names and all relationship names must differ. Help me rename them.

AI response 6: The AI suggested names for duplicated or unclear relationship and attribute names. Some suggestions were broader than needed.

Prompt 7: I clarified that I only wanted to rename the names that were the same, not all names.

AI response 7: The AI narrowed the renaming advice and focused only on duplicated names that could cause problems in the ER model notation.

Prompt 8: I wanted a different name than "has" for the relationship between ActivityTypes and ActivitySessions because an activity session is a concrete occurrence of an abstract activity type.

AI response 8: The AI suggested relationship names such as instance_of, occurrence_of, and realization_of. I chose instance_of because it clearly represents that an ActivitySession is an instance of an ActivityType.

Prompt 9: I asked the AI to help organize the data requirements documentation for my already-created ERModel_v07 by identifying the visible entities, relationships, attributes, keys, and logical attribute restrictions.

AI response 9: The AI produced an organized draft/checklist based on my existing ERModel_v07. I used it as documentation support, then manually reviewed it, corrected mismatches, and updated the final documentation according to my final ERModel_v08.

Prompt 10: Can you write it in TracWiki notation?

AI response 10: The AI converted the data requirements section into TracWiki notation so it could be added to the project wiki.

Prompt 11: I asked about the relationship between FullMembers and OrganizationalFunctions because a full member can technically have one board and one non-board function in the same mandate.

AI response 11: The AI explained that if exact start and end dates matter, the relationship could include valid_from and valid_to, or be modeled through a separate assignment relationship/entity. I later decided to ignore this and keep only the mandate attribute.

Prompt 12: I asked whether the key of EventSessions should include es_start_time, location, est_name, and the composite key of EventEditions.

AI response 12: The AI first gave an incomplete answer, then after my correction agreed that because EventSessions is a weak entity identified by both EventEditions and EventSessionTypes, the primary key should include the key of EventEditions, the key of EventSessionTypes, and the partial key attributes of EventSessions.

Prompt 13: I asked the AI to check version 08 of the ER model and the newest data requirements.

AI response 13: The AI reviewed ERModel_v08 and the written data requirements, checking consistency between the diagram and the text.

Prompt 14: I asked the AI to check everything one last time.

AI response 14: The AI checked the ER model and text again and pointed out remaining inconsistencies or small issues.

Prompt 15: I asked the AI to check everything again.

AI response 15: The AI repeated the consistency check between ERModel_v08 and the TracWiki data requirements.

Prompt 16: I asked the AI to check everything again because it kept finding things.

AI response 16: The AI continued reviewing the model and the text, focusing on whether the keys, relationship names, weak entities, and descriptions matched the diagram.

Prompt 17: I asked why names such as EventEditions were rendered as broken links in TracWiki.

AI response 17: The AI explained that TracWiki automatically treats CamelCase words as wiki links. It explained that putting ! before such words prevents automatic linking.

Prompt 18: I asked the AI to rewrite the text so that ! is put before every CamelCase name.

AI response 18: The AI rewrote the TracWiki text and escaped CamelCase entity names such as YoungMembers, FullMembers, MembershipStages, OrganizationalFunctions, ActivityTypes, ActivitySessions, EventTypes, EventEditions, EventSessionTypes, EventSessions, and CoreTeamFunctions.

Prompt 19: I asked whether the syntax [[Image(https://develop.finki.ukim.mk/projects/bestskopjehub/attachment/wiki/ERModel/ERModel_v08.png)]] is how to include an image in TracWiki.

AI response 19: The AI confirmed that this is valid TracWiki image syntax when using the full attachment URL. It also explained that if the image is attached to the same wiki page, a shorter form such as [[Image(ERModel_v08.png)]] can be used.

Prompt 20: I asked the AI to help write the required AI Use section and the ERModelAIUsage page.

AI response 20: The AI drafted the AI usage documentation structure and explained how to document the use of AI honestly.

Conscious assumptions and creations done through the help of AI

The following changes were made to my ER model and documentation after using the AI tool:

• Clarified that attendance and RSVP are modeled for ActivitySessions, not for EventEditions or EventSessions.
• Kept core team membership implied through accepted applications instead of adding a separate core team membership relationship.
• Treated Main Organiser as a CoreTeamFunction.
• Removed unnecessary application review data from the model scope.
• Kept event/session eligibility as business logic instead of modeling it explicitly in the ER model.
• Kept the project limited to UKIM students.
• Kept assemblies outside the project scope.
• Kept the specialization for members because it clearly represents observers, young members, full members, and alumni.
• Treated board membership as an organizational function/role rather than as a separate membership stadium.
• Renamed duplicated attribute names only where needed.
• Renamed the relationship between ActivityTypes and ActivitySessions to instance_of.
• Confirmed that EventSessions is a weak entity identified by both EventEditions and EventSessionTypes.
• Confirmed that the key of EventSessions includes the composite key of EventEditions, the key of EventSessionTypes, and the partial key attributes es_start_time and location.
• Added or corrected the written data requirements so that they match ERModel_v08.
• Escaped CamelCase names in TracWiki notation using ! to prevent unwanted wiki links.